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ABSTRACT : 

Design of digital electronic systems for a range of 
applications such as the functions of small ships requires 
a unified approach which does not make a priori choices 
between hardware and software. Throughout the several 
levels of digital system structure, the design procedure is 
portrayed as a task of preparing a program and translating 
the program into successively different languages. One 
language is the language of Functional Program Modules. 

These modules are versatile, effective, program control and 
operative modules which can easily be configured (programmed) 
and can be used with methods which automatically produce 
assembly and maintenance information. Examples, extensions 
and applications of FPMs are discussed. 

This is the final report of a task funded by the Naval 
Electronics Laboratory Center under Work Request No. 2-9104, 
amendment number one, 17 April 1972. 
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FOREWORD 



This report was prepared in an effort to describe some of the most impor- 
tant concepts which are fundamental to the design of digital information systems. 
The report grew from an answer to a question from Mr. Norman Tinklepaugh, and 
was meant more to provide a background and a base for further discussion than as 
an immediately applicable product. Time to develop the answers was supported by 
funds from projects under the cognizance of him and the Division Head of the 
Naval Electronics Laboratory Center’s Advanced Modular Concepts Division (Code 
4300), Mr. William Dejka. I thank both these men for their suggestions and 
assistance . 

V. Michael Powers 
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FUNCTIONAL PROGRAM MODULES (FPMs) 



AND DIGITAL SYSTEMS DESIGN 

1. Introduction 
1.1. Scope 

This report collects for review some thoughts about present and near- 
future concerns in digital systems design, particularly with respect to module 
selection and modular design methods. 

The discussion focuses on a particular range of families of digital 
modules which have attractive possibilities for future use in system design. 

Enough consideration is given to the general design problem, however, to place 
this discussion in a general context. 

A particular concern of the report is to emphasize the commonality 
between so-called "hardware" and "software" design. In spite of the fact that the 
two types of activities are considered separate in many organizations today, it 
is believed that separating the design activities for digital systems into 
hardware and software is detrimental to the objective of obtaining the best mix- 
ture of programming and devices for a given system. Furthermore, the knowledge 
and procedures involved in both activities are so similar and related that 
attempts to improve the overall system design process benefit from ignoring the 
superficial differences. It is recognized that the individual computer programmer 
need not be a circuit designer, nor vice versa, but the system designer needs 

knowledge of both. 

The later sections of this report discuss a particular set of commercial 
modules, along with some extensions and generalizations. The emphasis here 
is on the implications of the use of similar modules, rather than on the parti- 
cular characteristics of these devices. 
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1.2 Small ships electronics systems 

The subject of this report has direct bearing on the design of electronic 
systems for small ships because of the extensive use of digital information 
svstems deemed necessary to fulfill the unique small-ship requirements. 

The general requirements of the instrumentation of small ships include 
nearly all the functions found elsewhere in the Navy, but they also include 
tiehter restrictions. The systems must be effectively maintenance- free over 
reasonable- length mission, the equipment must be even smaller, lighter and 
more environment-proof than ordinary, and the functions of the system must be 
implemented in such a way as to require minimal manpower for operation. In 
addition, the operation of these vessels must include all of the types of 
tactical functions which are required aboard their big sisters, and must be 
extremely responsive to remotely commanded control. 

Necessarily, the solutions to the small ships problems will include 
solutions to problems in common with other ships. Thus the attributes not unique 
to small ships will lead to results which benefit others, as well. 

The solutions to the problems of creating complete systems in smaller 
packages will give better unified systems, designed with intelligent use of 
more highly automated techniques. The solutions to the lower manpower require- 
ment must be better integration among subsystems, better cooperation among their 
respective functions, and more effective approaches to the operator interface. 

The solution to the problem of widely diverse, changing sets of mission re- 
quirements can be the use of faster techniques for producing effective designs, 
coupled with a wide-ranging approach which provides the capability of easily 
reconfiguring the system among different ships, or between different missions of 
the same ship. This report includes discussion of the design approaches necessary 
for producing such effective, adaptable organizations. 



1.3 Soft, firm and hard wares 



As described in Section 2.2, a statement of the steps to be performed with 
a particular set of equipment in order to compute a certain result is a program. 
Depending on what equipment is being used, this program may take on one of sev- 
eral forms. If the sequential order of the program steps and the steps them- 
selves are completely expressed in terms of the equipment itself, they comprise 
a hardware program. Thus, hardware connotes a fixed organization; a sequential/ 
combinatorial logic circuit; "hardwired” connections. 

If the program consists of a structure of instructions fed to an instruc- 
tion processor, and if the instructions are encoded in some easily changed medi- 
um than it is a software program. Specifically, a traditional computer program 
is software. It is a collection of statements written for a specific computer 
or written in a fixed language for an unspecified member of a collection of 
computers, but the program organization is "soft"; it is easily changed by the 
programmer. The computer program is written on paper, punched in paper cards or 
tape, or coded in electromagnetic field patterns on transmission lines, magnetic 
storage surfaces, ferrite cores or multistable electronic circuits. The opera- 
tions of the programs derive from the sequence of statements written in the pro- 
gram language, interacting with the progress (the state) of the program. If 
the program is accessible to computation in much the same was as the data, the 
program may be self-modifying. In contrast with a hardware program, a software 
program is generally a more pliable, transient form. It is more exclusively 
concerned with the pattern of the computation itself, and less with the mechani- 
cal details of realization. 
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Some programs are not conveniently defined as either hardware or software. 



The term firmware program has two simultaneous connotations. One is that the 
program has some similarities both to hardware and to software. For example, 
it might be expressed as an electronic circuit but contains stored patterns 
which are decoded into operations and which vary with the results of the opera- 
tions. The second implied meaning of firmware is that its degree of permanence 
is intermediate to two extremes; the program structure is neither hard nor soft, 
but firm. The microprogram in an IBM 360/30 resides in a card capacitor read- 
only storage. Microprograms in this machine are not self-modifying but the 
cards are easily changed. Such a machine might, by changing microprograms, be 
used as a standard 360, as an emulator, and as a machine for direct execution of 
a higher-level language, all in the space of a few hours. Particularly in the 
case of microprogramming, the term firmware is an invention required by the 
existence of programs which are neither clearly hardware nor clearly software. 

The distinction between hardware and software has two useful purposes. 

First, it is useful as a short abbreviated description as used by technically 
competent people. In any engineering problem, the hardware is the physical equip- 
ment: the software is the organization and the ideas. This is still true in data 
processing problems, but when one is concerned with the organization and pro- 
gramming of the physical system (the "software" of the "hardware") or the 
representation, coding, storing and transmission of the instruction stream 
(the "hardware" of the "software") , it becomes obvious that the distinction is 
neither precise or adequate. The terms are useful, to people who understand 
their shortcomings, as qualitative and sometimes transparent indicators. 
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Second, terms hardware and software are popular in external descriptions 
of technical activities. The ♦‘erms provoke vivid though sometimes misleading 
images, and they provide attractive handles for use by someone who wants to 
pretend he understands what is happening, or by someone who tries to manage or 
guide an effort without attaining such an understanding. 

The concern of this report is not with hardware or with software, but with 
organizations, operations, and the design and preparation of programs. In the 
next several sections, various aspects of this process of systems design are 
examined for the particular case of digital information systems. The most im- 
portant theme throughout the discussion is the manner of dealing with programs. 

A generalization of the attitude is, that program development must be carried 
out in a consistent and efficient manner without making a priori distinctions 
between hardware and software. An effott to design a large system which starts 
by making large-scale "hardware/software tradeoffs" is inviting premature, un- 
necessary restrictions too early in the design process. More meaningful large- 
scale choices are the organizational aspects such as centralized vs. dispersed, 
serial vs. parallel, synchronous vs. asynchronous, etc. Much later in the program 
design come the decision, for example, aS to whether a program module should be 
implemented in a traditional vs. innovative computing structure (read software 
for a general purpose computer vs. microprogrammed devices vs. hardwired circuits, 
if you insist) . An effort which proceeds in a balanced manner can lead to choices 
which are more soundly based on pertinent consideration of performance and re- 
sources, and which can easily be changed by modular replacement in the event of 
a change in requirements or a change in the available technological base. 
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2. Levels of organization 

A good system is a well-organized collection of properly chosen components. 

A modular system is a collection of relatively few component modules, each of which 
is relatively complex. But each module is composed of interrelated items, which 
themselves may be complexes of others, etc. For any given design, the components 
are the smallest invariant units of the design. The systems are the largest 
design units, and subsystems are convenient intermediate-level complexes. But 
one man’s components may be another man’s systems, in some different situation. 

We are led to conclude that a complex system design is best described at a number 
of different levels. 

2.1 Levels of design 

Bell and Newell (4) define the levels in the hierarchy of digital com- 
puter structures largely from the basis of considering the different activities 
of different technical practitioners. The "institutionalized positions" of 
logic designers and circuit designers are used as evidence for the existence 
of distinct levels. Their highest level (the so-called PMS level) has computers 
as structures and processors, memories etc as components. The next or 
programming level sees programs as made of component instructions, operators, 
etc. The three logic design levels are: 

the register transfer level - arithmetic units made from registers, 
controls, data operators; 

the sequential switching circuit level - counters made from flipflops, 
latches , oneshots ; 

the combinatorial switching circuit level - encoders, selectors, iterative 
nets made from logic gates. 
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The lowest level they consider is the circuit level where example systems 
(circuits) are amplifiers, clocks and gates and where the components include 
relays, transistors, resistors, diodes, delays. 

One difficulty with defining a level of design as the concern of an 
identifiable group of people is that this produces a passive view of past 
practice. A more appropriate criterion might be to identify a level of design 
with a design language: then 

"A system level... is characterized by a distinct language for 
representing the system (that is, the components, modes of combin- 
ation and laws of behavior) . These distinct languages reflect 
special properties of the types of components and of the way they 
combine.... The fact that the languages are highly distinct 
makes it possible to be confident about the existence of different 
levels." [4, p.4] 

This method of identifying the various levels of system design allows 
us to identify the most recently emerged levels, but it leads to a significant 
difficulty. Whenever it is difficult to decide whether two languages are 
"highly distinct", it is also difficulty to decide whether they define differ- 
ent levels. Thus there is no effective procedures, even in principle, for 
counting the number of distinct levels of system design. 

The number of levels, and thus the extent or depth of the levels, are 
not precisely known. This is one reason for introducing the supplemental 
identification of a level with the activity of a man or group of men; it 
solidifies the general identification of major levels, without concentrating 
on the the boundaries and without worrying about the fringes. 
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This view introduces a new notion: the span (depth) of a level is 
commensurate with the comprehension of a human being. That is, one historical 
reason for designing a large system in successive stages has been that the 
human designer has a certain limit to the range of detailed consideration 
which he can handle effectively. If the design process is to be automated, 
it might well be done in smaller steps (for the machines are notoriously 
inept at handling the intuitive associations which a designer employs) or 
larger (if the machine can cooperate by performing routine tasks and inter- 
face well with the creative skills of the human). The number and depth of the 
design steps is not precisely determined now, and may change drastically in 
the future. 

For any definition of a level of system design, however, the design lan- 
guage is the key to the existence of a level. The language defines the level; 
is the tool for designing at that level; expresses the components and systems 
of the level; and provides the documentation for design at that level. The 
lowest-level, irreducible units of a design are the primitives (words) of the 
language; the system structures designed at that level are the utterances 
(sentences) of the language. Preparing a design at a given level means writing 
a statement in the language of the level. The process of designing an entire 
system becomes a process of carefully translating statements in one higher-level 
language to successively lower levels. 

2.2. Programs 

Information processing machines are action-oriented; they perform oper- 
ations on their inputs and produce outputs. With rare exceptions, they are not 
goal-oriented; they do not actively seek a "solution”. The driving force 
connecting a problem with its solution in terms of action-oriented processes 
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is the organization of the processes. Operating processor units are connected, 
sequenced, and in general, controlled, according to some predesigned scheme in 
an attempt to solve the problem. We call the specification of a desired 
pattern of operations an algorithm . The realization of the algorithm in terms 
of available mechanized operations is a program . 

Although useful in the present context, this distinction is not universally 
accepted. One definition of an algorithm, which derives from work by A. A. 

Markov, requires that it be a specification of a sequence of operations which is: 

a. General: it operates correctly for any input in a specified domain. 

b. Conclusive: it uses a finite number of deterministic steps and always 
terminates . 

c. Definite: The specifications and the required operations are un- 
ambiguous and "universally comprehensible", [8]. 

Unfortunately, given a purported algorithm it can be very difficult if 
not impossible to determine whether or not it satisfies the three requirements. 
Algorithms must be written in some language; the choice of a language influ- 
ences how close the statement of the algorithm comes to meeting these three 
requirements. Use of a natural language such as English, along with standard 
mathematical notation, makes the statement more widely comprehensible, and some- 
times quite general, but can leave it ambiguous. Proving a statement correct 
has so far been accomplished only for restricted classes of problem structures 
for small problems. 

Practically speaking, however, algorithms must be written for distribu- 
tion, discussion and implementation. The Communications of the Association for 
Computing Machinery publishes algorithms. Their solution is to accept state- 
ments of algorithms written in one of a small number of widely known computer 
programming languages, such as ALGOL 68, or FORTRAN. In one sense, this avoids 
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the problem of writing the algorithm and substitutes a computer program. Pub- 
lishing a program has several advantages: 

a. It is universally comprehensible to the large set of people who can 
read the language; 

b. It is unambiguous to the degree the programming language is; 

c. It is subject to estimates of its generality (also published are 
certifications, statements attesting to a partial audit, or verification that 
the program operates correctly when run with some data by some computer system) 
but conclusive proof of the property that it always terminates correctly for 
all inputs in the domain is generally absent. 

3. Program Preparation 

Satisfying a functional specification means preparing a program to 
perform the algorithm inherent in the specification. Identification of this 
algorithm is often the most difficult step in this problem; even if the "user" 
thinks he knows what he wants , he will usually change his mind before the final 
product is produced. A competent designer, knowing he is faced with incomplete 
and changing requirements, has two defenses. 

First, he builds systems which not only perform well in the specified 
environment but which also perform moderately well over a reasonable range of 
conditions. Such a design, which is able to stand up well under a broad range 
of conditions. Such a design, which is able to stand up well under a broad 
range of conditions, is technically known as a robust design; the concept is 
illustrated in Figure 1. 

Second, the designer prepares to meet changing requirements by building 
a repertoire of techniques to respond quickly. This repertoire includes 
carrying out each necessary design step in a somewhat generalized manner, so 
that changes in performance requirements or operating conditions can be 
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propagated through the design levels from top to bottom with a minimum of 
extra effort. But probably the most important part of the designers repertoire 
is the ability to use modularization. 

Of course, systems are constructed as an interconnection of discrete 
modules for a number of reasons, including task management, reliability and 
fault isolation. Modular design is stressed in this section, however, as a 
means for achieving systems which are relatively easy to redesign. A change 
in the specifications for a modular design can often be implemented by changing 
the parameters of a few modules and adjusting the interfaces, without dis- 
turbing the rest of the design. 
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Performance 




A. "Optimized" system; best performance at the design point, but poor 
performance at nearby, reasonable conditions, 

B. Robust system; performs well under a variety of conditions. 



Figure 1. 



A Cartoon Showing a Robust Design 



The design problem in general is to implement a required function (a 
component of a higher-level system) as a system of a specified set of lower- 
level components (themselves, perhaps, systems of still lower-level components) 
according to a specified technique of description. Thus, for example, a cir- 
cuit design problem might be to design the logical inter-connection pattern 
of a JK flipflop composed of resistors, capacitors, diodes and transistors 
according to the transistor-transistor logic (TTL) technique. 
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3. 1 Traditional software generation 

As background and to provide a contrast with the attitude in the 
remaining sections of this report, it is worthwhile to briefly consider some 
aspects of computer program generation. Traditional software generation here 
refers to the writing of computer programs in a procedural compiler or assem- 
bler language, and the subsequent processing (conversion) of these programs 
to machine code for execution in a general-purpose computer. No attempt 
is made to survey the entire field. Instead, a few comments are made about 
concepts which will probably be found in a Navy program generation center within 
a few years. 

One concern which will continue to be important is the topic of proper 
documentation for a program. The Navy has recognized that in order to monitor 
the production of a program, in order to maintain the product, and even in 
order to properly use the product there must be adequate documentation. The 
reason documentation has notoriously been inadequate and behind schedule is 
that it has been considered as something separate from the design. This atti- 
tude toward documentation is perhaps the only distinctive difference between 
‘’hardware" and "software" designers. For mechanical hardware, all of the design 
is recorded on paper — drawings, schematics, analysis. For computer programming 
where the code is the product, the softness itself contributes to its disparity 
with other documentation. Sufficient and proper documentation of programs will 
not be achieved until coding the program into a programming language becomes 
merely another design step, and not so much an artistic creation Then the design 
step which we now know as coding will contribute to, not distract from, the 
program documentation. 
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The practice of designing a large system as a collection of smaller tasks 
is universally accepted as necessary just to complete the job. The fundamental 
benefits of modularity (in specification, design, production, maintenance and 
update activities) accrue only when the modules are carefully chosen with respect 
to their functions and interfaces. Unfortunately, it appears that near-future 
practice in Navy command and control projects will be dictated by a heritage 
from NTDS and the influence of a few major manufacturers 1 organizations. Modules, 
by way of NTDS practice and collateral "standards”, seem to be predefined in 
terms of operations which derive directly from machine and language artifacts, 
e.g. subroutine calls. Interfaces often occur in the form of control blocks or 
parameter lists. Consequently, designers of each module are encouraged to acquire 
and use knowledge of details (such as the bit structure of a control word) which 
must be handled identically by several different modules. In some primitive 
forms of data base design, the programming details of each module which accesses 
data are largely dictated by details of the specification of the data base. The 
severe problem caused by this widespread interdependency occurs because the 
design process is not a unidirectional, one-pass activity. Even in the initial 
production of a program, changes occur as the design progresses. During and after 
the production of the first version of the system, analysis, experimentation and 
measurement results are reflected in changes in the amount and format of data 
which must be stored in these common areas. If the detailed structure of the 
common control block or the data base is known and used by the designers of several 
modules, all of them reflect every common block change in their own designs. 
Designing a system around common blocks thus seems like a method to maximize the 
interference among modules rather than minimize it. An alternative approach which 
minimizes the knowledge needed by one module designer about internal details of 
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modules, and therefore minimizes the interference of design changes, is being 
developed [9, 10], but it appears that widespread adoption of such principles 
in program generation centers will be long delayed. 

Another topic which should be given more attention, but which will probably 
not appear as changed programming practice in near-future program generation 
centers, is software reliability. Present program generation center attitudes 
seem to assume that a properly written and tested program is perfect. Perhaps 
it is, but software troubles show up later for two reasons. One is that a 
program tested at the Center may encounter in the field inputs which were not 
in the tests. Another reason is the volatility of the code; transient signals 
in the computing equipment and mechanizal errors in the program transfer equip- 
ment can change the program. Just as mechanical designers know that simpli- 
city in the basic design enhances the reliability of their product, so com- 
puter programmers must believe that unnecessarily complicated code leads to 
programs which are difficult to read, test and debug and maintain. If any 
complexity is to be added, it must be carefully chosen as protective redun- 
dancy — built-in data and program checks for reasonableness, consistency, 
bounds , etc. [ 15 ] . 

A final comment about the near-term trend of computer programming concerns 
both standardization and languages- Standards are vital in a mature field of 
design in order to insure compatibility among organizational units which are 
designed separately. Languages are the tools of design, and the use of standard 
tools can help in producting standard products. But to "standardize” all of the 
Navy’s command and control programs by requiring the use of an inappropriate 
and antiquated language (FORTRAN seems to be an attractive candidate to some 
people) is to require inappropriate solutions and to legislate inefficiency. 
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Indeed, if such attempts are carried too far, they seem to be efforts to use 
"s tandards" or pro forma solutions, and to abdicate the basic responsibility of 
design, which is to select, configure and interconnect appropriate elements in 
the manner which is most appropriate for the application. 

A recent tendency related to standards and languages is the topic, recurrent 
in literature concerned with Navy command and control systems, of ’’high level" 
languages. This is partly an over -reaction against the primitive assembly lan- 
guage - like constructs still found in CMS and CMS-2 programs. The best pay- 
off, in terms of portability of programs, will not be found by legislating the 
universal use of "high level" languages in hopes that this will guarantee machine 
independent code (it won’t), but rather by allowing more freedom in the choice 
of language and by encouraging the consideration of portability in the entire 
system design. If computer program generation were a mature design process and 
less an art, there would not be a need to require a certain language. The de- 
signer would choose the language appropriate for the task at hand. As it is 
now, the degree of machine independence is much less a function of the language 
used than of the way in which design structural information is or is not employed 
Programming in a "high level language" does not imply "high level thinking"; in 
fact, many unrealistic dreams can be punctured by a little "low level", informed 
reasoning. 

3.2 Life cycle considerations 

As mentioned in the preceding section, the activities involved in producing 
today’s Navy software systems often seem to assume that the job is finished when 
the program is written. This is patently false. Even so, the present mode is 
to contract for the procurement of a deliverable program without sufficient 
specifications or tests for its future performance characteristics. 
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The procurement of any system goes through a number of phases in its life. 
Successful performance in one of these phases may be jeopardized by failure 
during an earlier phase to consider the future. Tradeoffs must consider the 
entire system lifecost, not just design or production. 

Listed below are several successive phases of the life of an arbitrary 
design. The life of a system is shown here as indefinite, in the sense that 
many of the original components will be replaced, and the system is capable of 
continued evolution. The reason for listing these phases in this report is to 
abstract some system characteristics which are independent of the hardware/ 
software nature of the implementation. Hopefully, system designers of today can 
read such a list and find it equally familiar and equally pertinent, whether they 
are thinking of software systems of program modules, mechanical systems, or 
logic systems of hardware, firmware or whatever modules. Hopefully, too, a 
system designer of the near future could read the same list and find it quite 
familiar. He will know that what is implied is any arbitrary mixture of hardware 
and software and hybrids; the choice will be made (and can be changed) at the 
level of a specific subsystem. He will probably not even care that at some 
time in the past people considered software system design and hardware system 
design as different activities. 

The creation of a system begins with its specification. The first design 
step is to develop performance requirements or statements of how the system 
is to relate to the world, how it is to be used, and to reflect that use into 
functional specifications, a statement of the functions which must be imple- 
mented in order to satisfy these needs. Unfortunately, this phase of the design 
is sometimes the most difficult. Especially in the case of new information 
processing systems, it is difficult to predict the user requirements for a 
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capability that has not existed before. A good example is the public experience 
with timesharing systems. No designer knew the wide diversity of uses which 
would be asked of such systems until the first ones were built. No one knew 
the performance demands until there were users. This difficulty is still present; 
see for example the decisions being made about page replacement algorithms 
for the AADC , without knowledge of what the actual performance requirements 
(in terms of the dynamics of AADC program working sets) will be [11]. 

Design of the system proceeds from functional specification through vari- 
ous phases of organizational or structural description to design of the complete 
system as interconnections of cooperating processes. Each process might be a 
component procured from another source or it might be a subsystem which itself 
is subject to design. Other sections of this report have more to say about the 
methods and tools of this series of modular design steps so here we will only 
add a few comments. If the complete system is to have any of the desirable 
attributes of reliability, maintainability, portability; if it i s to be subject 
to verification and test, monitoring and measurement, redesign and upgrade, the 
capabilities for providing the means must be built into the design. Specifica- 
tions for providing the measurement hooks, for detecting, locating and isolating 
errors, for module replacement must be built into not only the equipment but the 
design information. Ideally, the successive refinements of the design become 
the basic documents of the system. 

As modules and components are specified more precisely, the design steps 
become experimental production steps. The only difference worth noting here is 
that gradually the system begins to exhibit some of the originally required 
functional specifications and some of the capabilities in the original performance 
specifications. A vital point here is the necessity for testing each step of 
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the gradual combination of modules to verify the validity and performance of the 
combination . 

If the organization of the system is sufficiently modular and if the inter- 
faces are well designed, the system is amenable to successive updating cycles 
starting with the experimental production phase. In fact, for large first-time 
systems, applying several rounds of updates to portions of the experimental 
production model seems to be the most common way to produce an operational systems. 

Two more phases of activity concerning the life of the system, training and 
maintenance, must be mentioned. These are the activities which use the features 
of design which are mentioned above, but which in practice are often ignored as 
being incidental to the primary purpose. The functional subdivision and organiza- 
tion of the system can be exploited in training people to use, operate and 
maintain it. The modular nature of the design can be an aid to isolating and 
localizing difficulties which need maintenance. The designed-in protective 
redundancy can minimize the effect of errors, and designed-in test measurement 
facilities can help in quick repair. 

3.3 Means of program preparation 

If creating a design to meet a given set of specifications means preparing 
a program to perform the desired function, then it can be seen that a fundamen- 
tal asset to a designer is a set of tools and techniques to help him prepare 
programs. As these tools become more comprehensive and more thoroughly 
mechanized, they become elements of design automation. "Design automation 
is ... a way to reduce design time and overall product cost, ... a [a way to 
provide] documenting, ... analysis ... and synthesis functions..." [12]. 

The present situation in the field of automation of digital (hardware) 
systems design sees computers being used in several ways. As described in a 
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recent survey article [5] systems are used for simulation, synthesis or 
translation, partitioning, placement interconnection and fault test generation. 
Simulation capabilities are concentrated at the gross system level, the gate 
level or the circuit level; relatively little attention seems to have been 
payed to intermediate level simulation (exceptions are more carefully 
examined in Section 4 of this report). Aside from simulation, other 
functions of equipment design automation seem to be mainly concerned with 
low level organizations such as gates or circuits. An example is the class 
of partitioning problems; given a system of low level components (i.e. a 
conventional gate level logic design containing thousands of gates) , 
separate the system into several parts. Optimization is attempted with 
respect to number of connections, number of parts, number of types of 
different parts, etc. The goal of this class of problems is similar to that 
of several other efforts; to specify system building blocks. The difference 
is that the partitioning problem starts with a particular low-level design 
and groups components. Functional modularization efforts, in contrast, 
try to identify modules which perform a certain action which can be found 
in many different designs, and to design systems using these modules. 

4. Functional Program Modules (FPMs) 

4.1 Design as configuration 

One of the characteristics of the classification, "small ships", is its 
diversity; the types of operational requirements vary greatly. An integrated 
approach to the preparation of information systems for small ships must face 
the problem of assembling systems differently tuned to the different requirements. 

One solution to the problem is to design a general purpose system which has 
every one of the capabilities required by each of the ships for each of its 
possible missions. Of course, previous design experience has taught us that 



the overhead required to provide all these capabilities, to integrate them, and 
to manage them, costs dearly in terms of the physical parameters of the system, 
such as weight , size, power, and the operational parameters such as maintenance, 
availability, efficiency and speed of processing. 

Another characteristic of this class of ships is their small size; a large 
general-purpose information system here is competing for scarcer space, receives 
fewer inputs, and feeds fewer outputs chan its counterparts in larger vessels. 

For these reasons it appears obvious that the small ships electronics 
effort requires special-purpose configurations of functional components. Appar- 
ently the main task is. given a specification of the operational functions to be 
performed and given a physical ship configuration of sensors, weapons and control, 
to configure the signal processing functions necessary to accomplish the opera- 
tions in the best possible way. Several auxiliary problems immediately arise; 
preparing the operational specifications, deriving the functional specifications, 
discovering the pertinent sensor, weapon and control characteristics. But the 
configuration problem, or the design problem, is particularly interesting. 

The design problem is too big. It is beyond the present techniques to pro- 
ceed in one step from operational specifications to wiring diagrams, physical 
configurations and machine language computer programs which accomplish the goal. 
This design step is too long, for the same reason that ABM opponents say the 
system cannot work; the design procedure cannot today cross the many levels of 
successively finer detail in a single step. Instead, the process proceeds 
from one level to a lower and arrives at a detailed design after a series of steps. 

An idealized design procedure in the technology of the 1950 f s or 1960 f s 
for example, might start with a loose statement of operational functions of a 
platform. This statement, when compared against available technology, might 
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result in functional specification of a ship’s hull, propulsion, personnel, 
sensors, weapons, communications, and information processing. Each of these 
areas would then be carried to the next lower level. The information processing 
level, for example, might be carried to the level of specifying a configuation 
of computer systems, preprocessors, convertors, modems and mechanical and human 
interfaces. Another design step then might be required from the computer system 
to the specification of processors, memories, controls, channels and peripherals. 
The design of the processor might be accomplished at the level of data operators, 
registers, busses, decoders, controls and interfaces. The next lowest design 
level might be the logical design of a subsystem such as an arithmetic-logical 
unit in terms of combinational and sequential logic elements such as gates and 
flip-flops. Finally, the circuit design implements a flip-flop, for example, as 
a configuration of resistors, transistors, capacitors... A resistor is designed 
too, but this is carrying things a little too far, even for the era of 1950. 

The multilayered design process as described above is idealized to make a 
point. No mention was made of the physical, operational and political constraints 
on the design step between any two levels — these constraints are the factors which 
make the design step a design problem. The process was described as a straight- 
forward, top-down, step by step procedure. In reality, each step loops back to 
previous higher levels and iteratively interacts with the higher level design 
problem. Finally, many of these design steps are not required for a given 
project. Off-the-shelf components are used at some level. The information 
processing system for a given ship, for example, may be designed as a configura- 
tion of available computers with available interfaces to already stocked sensor, 
communication, fire control and navigation subsystems, using previously pro- 
cured displays and consoles. These deviations from reality in the above idealized 
picture, however, do not destroy the main point — that the design of a system to 
meet operational requirements is a sequence of steps, each configuring an element 
of a higher level from components at a lower level. 



4.1.1 Standards as design 

Every designer uses standards such as the industry-wide standard sets 
of functional parameters, physical dimensions or calling sequences. Next to the 
principle of assembly-line manufacturing, the wide use of standard components is 
probably the most important factor in this nation's industrial successes. Infor- 
mation processing designs are evolving standards of their own. 

The designer also relies on standard design techniques. Each industry 
and each design group has certain common conventions which make design documen- 
tation more easily comprehended across the group. Thus, each of the designers 
involved can readily understand and contribute to the design. The main benefit 
in standard design formats and conventions for structural drawings, flow charts, 
logic diagrams and programs is that the information recorded tends to be concise 
yet unambiguous. A second benefit is that required formats make it easier to 
insure that all the necessary design criteria are satisfied and sufficiently 
documented . 

Standards in use among several different groups contribute to compatabili ty 
of their separate products, but do not insure compatibility. The improper use of 
standards can interfere with the design efforts. If inappropriate "standards" 
are externally enforced they can require inappropriate design measures. For 
example, TADSTAND 2, 8 Nov 1971, specifies that the standard for tactical data 
system program documentation is given by Weapons Specification WS-8506. WS-8506, 

for example, partially defines the structure of the program by defining such 
pervasive terms as program, subprogram task, common data base, constant, etc. and 
requires documentation in these terms. A design of a system which is based 
on a different set of elements (a multiprogramming, virtual machine concept, for 
example) might not conveniently fit this format. Either the design must be 
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recreated for the purpose of documentation alone, or (the path of least re- 
sistance) the preferred program structure will be abandoned in favor of a 
"standard' 1 approach which allows documentation as part of the design process. 
Misuse of inappropriate standards can be a substitute for good design. 

4.1.2 Design/ configuration aids 

A major thrust of research in signal processing systems architecture 
has been to make the design step easier, faster and more highly automated. 

The historical progress of technology throughout the world has been the in- 
creasing ability to produce increasingly more complicated designs by succes- 
sively incorporating more and more of the knowledge and techniques from pre- 
vious designs. 

Development of the effective techniques for the design step at any given 
level requires three things: identification of the levels of organization 

involved in the design, development of a language for expressing the design, 
and development of techniques for translating the higher-level requirements 
of the design to lower-level specifications which realize the design. All three 
of these are usually accomplished gradually for a given design level. 

The decis ion as to which components are taken as elementary units for 
a design level, and which are to be considered elements (systems) of a higher 
level, is generally an evolutionary process. Subsystems which are repeatedly 
designed and manufactured with essentially similar functions become, over a 
period of time, components for design at a higher level. Thus flipflops be- 
come components of logic designs, registers become units of arithmetic de- 
signs and arithmetic logic units become units of central processor designs. A 
subsystem becomes a component when its design is established, when it finds wide 
application in a number of different places, when it becomes available as a unit 
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from some source, but most importantly when a designer finds it convenient 

to use it as a unit in larger designs for purposes of comprehension, documentation 

and management . 

The language of a design level also grows gradually, being composed 
partly of notation from the lower, more detailed level and partly of generic 
forms common to many design levels, such as signal flow block diagrams and flow- 
charts. However it arises, the language is the vehicle for describing two 
vital parts of the design: the structure of the system (its logic inter- 
connection) and the function of the system (its logical operation) . 

Techniques for translating system design requirements from one level 
of description into realizations in terms of organization of components at the 
next lower level of description gradually arise as the components become 
identified and as the language definition evolves. Many examples come to mind 
from the field of computer software design. Assemblers developed as the 
translation tools from the assembly language level of labels, opcodes, addresses 
and modifiers to the machine language level of bit patterns (fields) in com- 
puter words. Macro assemblers developed as the translators of functional 
patterns to assembly language code. Compilers arose as the translators from 
imperative statements (e.g. X = A + B - 2,**Y) to lower levels of macros, 
assembly language or machine code. Linkage editors and loaders developed as the 
tools for translating the job control language for specifying a system of 
interconnected programs into the actual package of executable code, constructed 
from modules developed at the next lower level of program design. Operating 
systems now have developed to the point where they implement the actions of 
jobs by manipulating the physical computer system, allowing the applications 
programmer to use convenient, idealized, and sometimes imaginary memory, 
operations, and communications. 
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4.2 Register Transfer Modules (RTMs) 



One approach to the design problem at the register-transfer level is 
embodied in a set of design units known as Register-Transfer Module (RTMs) 1 . 

The effective use of these modules requires an understanding of the register- 
transfer design level, an understanding of flowcharting language statements, 
rules and components, and a cautious consideration of the costs in equipment 
and efficiency when the technique is applied to systems which are too large 
or too small . 

4.2.1 Origin of RTMs 

RTMs are a realization of the register- transfer level of design as described 
by Bell and Newell [ 4 .. p 3—11 ] - It is that level which is concerned with design of 
systems such as arithmetic units from components such as registers, transfers, 
controls and data operators. Another approach to a quite similar level has been 
reported by Chu [6,7], but this work concentrates on the use of an intermediate 
language called Computer Design Language (CDL) . CDL is essentially a language 
for simulating sequential digital computers whose structures are similar to con- 
ventional second or third-generation general purpose computers. Certain features 
of the language make it difficult to apply to innovative designs involving such 
features as a hierarchy of nested levels or parallel or subroutining organizations. 
The RTM approach has two important differences; it is a general approach to design 
at the register-transfer level, and it leads not just to simulation but to hard- 
ware realization. 

The basic components of the RTM method are, as described by Bell and others 
[1,2], realizations of components derived from the PMS level of computing struc- 
ture descriptions [4, esp. pgs . 10-20]. The operations (funtions) performed 

Trademark of the Digital Equipment Corporation 
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by the use of these modules are of course register transfers, described mostly 
in terms of action sequences in a nearly universally accepted version of 
the ISP language [4, esp. pgs . 22-36, and g] , viz: 

A — A+B 

By concentrating on the register- trans fer level of design rather than on the 
structures to be built from this level, the RTM technique has acquired a wide 
generality in the possible type of application. 

As described by Bell and Newell, digital systems have memory (M) , data 
operators (D) , transducers (T) and controls (K) . Other types of components 
are involved, but these are enough for examples. Different forms of these 
components are described in the PMS notation by strings of abbreviations and 
numbers, arranged to be quite sensible by someone with digital system design 
experience. The influence of the PMS descriptive system is shown in the 
names of the following examples of elementary functional RTMs : 

Ksimple (or Ks) , simple control. Upon receiving a signal from a logi- 
cally preceding module (another K) , the Ks issues a signal to evoke some 
specific active such as a data operation and transfer, and when the Ks receives 
notice of the completion of that action it passes a signal to the next element 
(K) , which, typically, controls the next step in the program. 

Kdecision (Kd) . According to the state of some logical variable in the 
system, the Kd passes the control sequence to one or other of two following 
sequences, implementing a program branch. 

DMgpa (A, B) . A general purpose arithmetic data operator with (16-bit) 
memory registers A and B. Performs elementary fixed point binary addition and 
subtractior and several logical operations such as shift and logical AND. 

Kbus . A bus control. Provides a memory register to latch the content 
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of a signal bus, provides a means for controlling bus operation and for sensing 
simple conditions on the bus. 

Many more modules are possible; some have been implemented by DEC and 
others have been described and used in other descriptions. But these few form 
the nucleus of a capability for programming. 

Figure 2 shows a program, complete except for input and output, to imple- 
ment a nearly trivial example algorithm: 



A similarly sequenced FORTRAN-like program segment for this algorithm is: 
S=0 

READ N 

100 IF (N.EQ.O) GO TO 200 

S=S+N 

N=N-1 

GO TO 100 

200 WRITE N 

Aside from possibly a few flowchart conventions, Figure 2 completely 
specifies the system. Automatic techniques such as those described later under 
the heading J, PDP-16" can be used to provide a description of the hardware in 
more conventional terms such as racks, circuit cards, power supplies, cables, 
wiring lists, etc. 

Instead of defining the RTM design language here, we will let Figure 2 
stand as an example. The design language for the most part consists of flowchart 
symbols interconnected to show control sequences. As distinct from other flow- 
charting schemes, however, statements inside the RTM flow boxes are restricted 
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to simple expression forms at the register transfer level. A typical example 
is the data operation type: 

R l^ R 2 ° P R 3 

R 2 (optional) and R are source data registers, op is an operation 
specification, and R is a destination data register. Such statements are 
reminiscent of the elementary ’’triples" of the syntax analysis portion of 
traditional compilers . 

A striking feature of a typical R.TM design is the natural division be- 
tween the control part and the data part. On the left of Figure 2 are the 
interconnected control modules. The module types (Ks and Kd) and their con- 
nection pattern characterize the structure of the program. On the right, the 
data operators and bus(es) characterize the implementation of the operations 
of the program. Between the two parts are a large number of interconnections. 

Because the control part, with data operations specified inside the 
flow boxes, almost completely determines the connections to the data part, 
and because the data part is essentially the same for most simple examples, 
many of the examples of RTM designs given elsewhere show only the control part. 
4.2.2 PDP-16 

The Digital Equipment Corporation markets a set of RTMs bundled with 
design services (personnel and PDP-10 programs) and collectively called the 
PDP-16 [12]. The marketing effort appears to concentrate on a part of the 
activity served by their Control Products group. The PDP-16 method is pre- 
sented as appropriate for design of fixed-program industrial control systems 
which are neither too simple (<20 bits of memory, <20 control steps) nor too 
complex f>lK words of memory, >250 different control steps) . Smaller systems 
are described as appropriate for design by "standard” logic modules, and more 
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complex systems are characterized as appropriate for the use of minicomputers. 

DEC has strong vested marketing interest in both of these alternative design 
methods . 

A most attractive part of the PDP-16 system, from the point of view of a 
customer, is the idea that designs are implemented directly from the flowcharts. 

The flowchart elements represent the actual hardware which will be used for 
sequential program control and for data operations. From a flow chart provided 
by the customer (DEC gladly provides this, too, for a price), the design aids 
produce listings for module insertion, wire wrapping, checkout, installation, 
and maintenance. Card decks or paper tapes for automatic wire wrapping machines 
can be obtained directly. 

4.2.3 RTM Simulation 

Once the basic feasibility of implementing has been established by building 
and testing some basic modules, and by using them in some sample designs, attention 
turns to alternate and expanded sets of modules. As explained in the previous 
section, the RTM modules which have been built are mostly based on the descriptive 
system for digital computers. The PMS language is a generalized attempt to 
describe the structure of any general-purpose digital computer at the highest 
level. The RTM modules are described by PMS notation, and seem to have been se- 
lected to correspond in large part tc the major units of the PMS scheme. Devi- 
ations and modifications from this correspondence seem to have resulted from 
consideration of the packaging of the physical modules themselves. When attention 
is turned to design of dedicated special-purpose signal processors rather than 
general-purpose computers (and RTMs are recommended only for the former) , it would 
seem that perhaps a different set of modules would be more effective. For trial 
designs and initial evaluation of new choices for modules, simulation of their 
performance is preferred over actual physical construction. In preliminary phases, 
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simulation, when soundly based, provides quick, easy results and the convenience 
of flexibility in changing modules and their characteristics. Recent simulations 
[13] have included the following: 

Basic modules 
Ks imple 
Kb us 
Ktes t 
GPA 

Ari thmetic modules 
Adder 
Ktimes 
Kdivide 
Kb ranch 
Kboolean 

Floating point modules 
Fadd 
Fsub 
Fdivide 
Ftiraes 

Trigonometric 

Sinang 

Arcsin 

Angtan 

The "basic" module simulations established the soundness of the approach. 
The others were mostly extensions to provide useful functional units 
in a design for a particular problem ("triangulation"; computation of the lead 
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angle of intercept for a weapon) appropriate to a mobile defensive weapon plat- 
form, and for use in a demonstration of the feasibility of implementing with 
RTNs the fundamental FORTRAN computation/control structures. 

4.2.4 Other Examples 

Briefly described below are some of the applications to which the RTM 
design technique has been fitted. In each case the problem is briefly described, 
and a reference for further explanation is cited. 

1. Sum of integers. As in previous Figure 2- See also [2] p. 15, 

Figure 3 and [13], p. 20. 

2. Mul tiplication by the Booth algorithm forms a 16-bit produce from two 
eight-bit inputs. [2], p. 15 and figures 4 and 5. Illustrates use of two busses 
and the use of subroutines. 

3. A remote a/D sampling unit interfaced to a serial synchronous modem, 
[2], p. 23 and Figure 7. 

4. 16 x 16 multiplication [13], p. 32. 

5. Interfaces: from PDP-16 to 

a. PDP-11 

b. PDP-8e 

c. A IK x 16 bit core memory 

d. A 32 x 16 diode ROM 

reference: [14], pp . 148-155. 

6. An a/D preprocessor for a central processor. [14], p.29. 

7. A magnetic tape code translator [DEC tabloid flyer, p.5]. 

8. Small general-purpose computers. References: [2], p. 23; [1] p. 498- 

499. One was a computer very similar to the PDP-8: 



"...an RTM diagram for a small s tored-progr am computer that 
was initially constructed as an application experiment to 
demonstrate the feasibility of the modules and to investi- 
gate systems problems. The process of specifying the machine 
took approximately two hours (with three people). The computer 
was wired and, aside from minor sys tem/circui t problems (for 
which the experiment was designed) , the computer operated 
essentially when power was applied, since there were no logic 
errors . " [1 ] , p . 498. 

Other computers have been designed to emulate the PDP-8 and the Data General 

NOVA. 

9. Functional modules 

Within the basic programming conept, other modules have been designed. 
Some which appear to be helpful in use of functional modularity have been speci- 
fied and simulated ([13], pp. 16-21): 

a. integer multiply and divide 

b. floating point arithmetic modules 

c. trigonometric modules: Sine, Arcsine, Arctangent 

10. RTMs have been used in simulations to directly simulate FORTRAN 
functions such as assignment, branching, and DO loops. [13], p. 21. 

11. Triangulation 

RTM programs have been written for the triangulation problem; 
"computation of the lead angle of intercept for a defensive weapons system 
(airborne or surface) on an approaching target." [13], p. 22. The algorithm 
has two steps: 
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1. Given two marks (target sightings with range, bearing and time), 
determine target's relative course and speed. 

2. Given relative course and speed of target and relative speed of 
weapon, determine intercept bearing. 

4.3 Functional Program Modules 

The choice of which functions to implement as Register Transfer Modules 
was partly determined by the state of MSI technology, and partly by the intended 
marketing audience. When attempting to generalize the best features of these 
concepts and imagine improvements, it is sometimes difficult to maintain proper 
use of the RTM terms as copyrighted. Furthermore, when attempting to unify 
the fundamentally important concepts which are common to RTMs and many other 
systems, the specific nature of RTMs, especially the actual PDP-16 modules, 
are less than vital to the discussion. 

We therefore adopt the phrase, Functional Program Modules (FPMs) to stand 
for a set of functional building blocks applicable for direct implementation of 
programs . 

Approximately 20 different modules were initially postulated in the RTM 
system [1], and the list in a preceding section of simulated modules includes 
several additional ones. It is to be expected that early phases of development 
of any such system will initially lead to a large number of different modules 
(30 might be a reasonable guess) , in order to satisfy a wide range of applica- 
tions. As experience grows, however, two trends will reduce this number sign- 
ificantly. One is usage. The modules which are poorly conceived will find less 
and less use, and will disappear in favor of the better ones. The other 
experience trend will result from the maturation of the design level and 
adaptation of the FPM approach to better fit this level. Thus as the most 
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suitable defining terms, the most expressive language and the best organizational 
structures appear, a smaller, more effective set of modules will develop simul- 
taneous ly . 

It must be recognized that the modules have been chosen in order to give 
a sufficient and expressive set in which to express designs. No other effort, 
such as a search for a minimal set, has been allowed to directly influence the 
choice of modules; this certainly would detract from the attempt at descriptive 
richness in the language. 

A later development can be expected which might reduce the number. A 
reasonable expectation might be four to ten modules for a certain class of de- 
signs; a higher level of description might use a still smaller number of complexes 
of these modules as basic units, but would incur some inefficiency in the form or 
unused, redundant capabilities. 

For the present, it would seem that the modules to be developed, designed 
or simulated should include ones to perform essentially all of the operations 
under consideration as machine instructions for future digital computers, ([11] 
for example) such as: 

complete serial and parallel control instructions 
subroutining and stacking 
synchronization functions 

conversion (fixed/floating, scaling, rounding; polar/cartesian 
coordinates; time scales; BCD/binary and various graphic and 
communication codes) 

vector, matrix and higher-order array operations 
circular and hyperbolic functions and their inverses 
structured data operators 
logarithms and power functions 

2 

common algebraic expression forms such as ax+b , polynomials, x etc 
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As experience grows in any given application, common substructures will 
emerge; these often-used substructures will perhaps become standard modules 
themselves. Also in the course of developing the best set of functionsal pro- 
gram modules, certain simplifications will occur. For example, most of the con- 
versions listed above can be efficiently organized as a table lookup procedures, 
with the only difference being the contents of a read-only memory. 

It will be worthwhile, part way through this development, to devote some 
effort to developing a "minimal" set of modules. It may well be, for example, 
that the same single module with different ROMs will perform each of the required 
functions with acceptable efficiency - this could be one version of a "universal 
functional module." 



5. Applications and Conclusions 

5.1 Applications of Functional Program Modules 

As described in this report. Functional Program Modules have already proved 
to be effective in construction of a small number of data systems with inter- 
mediate complexity. The principles employed appear promising for further and 
wider applications in several ways. 

Perhaps the most important feature of use of the modules is the manner in 
which they interact with the rest of the design process. They promise to be 
very effective as components in a unified design system which is highly 
automated and thus extremely fast in responses to new design requirements or 
reconfigurations. The actual implementation of FPMs as a set of production units 
is somewhat less important here than the concept of a set of functions which 
can be used as elementary design components at the regis ter- trans f er level and 
above. It may well be that the best use of physical FPMs is as a set of bread- 
boarding modules for advanced development; a more compact realization might be 
developed for high-volume production. 

The FPMs not only interface well with the production-oriented part of 
digital systems design, but also lend themselves to cooperation with the 
analytical stages. The modules so far conceived are, as demonstrated in Section 
4.2.3, very well suited for use in simulations. 

Experimental module designs and system configurations can easily be sim- 
ulated for the purpose of evaluating a design and its analysis. For example, a 
simulated system might be configured and run with realistic inputs in order to 
discover or verify important characteristics about job-related statistics and 
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Interfaces and special-purpose units will be easily configured with FPMs, 



The FPM design approach will therefore be useful not only for configuration 
of overall system structures but also for validation of design and fabrication 
models of subsystems (which may or may not be designed according to FPM techni- 
ques). Simulated, breadboarded or manufactured subsystems can be connected to, 
and operated with, FPM-designed test beds for development validation. 

In addition to their use as functional data processing elements, FPMs 
appear to be well suuited for use as the control elements for cooperating sub- 
processors. Despite the compelling reasons for an integrated design approach to 
electronics systems, particularly for small ships, it appears that many of the 
near-future efforts will involve separate development of sensor, communication, 
computation and control functions. The best that can be done in such a situation 
is to integrate the many separate systems by a common control network in such a 
way as to promote their cooperation. FPMs are well suited for such a coordinating 
role, where some processes operate in parallel, others in serial fashion, some 
explicitly synchronized and others merely communicating. As described in the 
preceding sections and in the references, the very nature of the program design 
process has resulted in an effect control structure for FPMs. 

A portion of the FPM development effort should be devoted to analysis and 
testing of means for using FPM networks as programming structures for separately 
developed subsystems. 

5.2 Conclusions 

The use of Functional Program Modules as a set of components for digital 
systems design has been shown to be an effective and versatile concept, whether 
the modules are used as a convenient conceptual unit for design or as an actual 
physical unit for the design- to-cons truct ion continuum, or as a control program- 
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The feasibility of their use with regard to modern packaging techniques 
and emerging component technologies has not been fully explored. FPM development 
has not yet been oriented toward producing example applications which directly 
compete either against high-volume production of gate-level designs or against 
use of general-purpose computers of any size. Further work along these lines 
is needed. 

The gradual evolution toward effective use of modular, functional program- 
ming will continue, with or without any special attention from the Navy directed 
toward the modules themselves. But the evolution will be gradual, and it will 
proceed through a long period in which designers in each particular phase of 
signal and information processing and in each industrial organization will develop 
their own peculiar approach. From observations of recent activities concerned 
with general purpose computers used in tactical data systems, it seems there is 
a substantial danger that some one or several of these approaches might be fro- 
zen as ad hoc, through official, Navy standards. Or worse yet, there may be 
many: a weapons system standard, a radar standard, or sonar standard, an optics 
standard, a communications standard, ... etc. Each of these areas has its own 
particular concerns, and would naturally evolve a somewhat different organization 
of modules. The only hope of compatibility in function would be through externally 
enforced interface specifications. Clearly this is less than the best of sit- 
uations . 

Much better is the prospect that is presented by the case for a general 
development plan for a set of Function Program Modules . The FPMs developed in 
this manner would be effective for a wide range of naval electronics systems. 

These modules will necessarily be individually efficient for use in each of 
the several operational specialties, but unified development from a common base 
will natually and easily lead to cooperating interfaces and minimal diversity 
in logistic and maintenance support. 
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Most of this report has considered FPMs as modules which perform as well 
as control their functions. There are corresponding data operators and program 
control units. The latter are the most important, and may have some applications 
to the control of independently developed signal or data system processors. The 
most important feature of the FPU method is that it presents a unified approach 
to the problem of creating designs which include cooperating components within 



a complex system. 
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